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Abstract 

NASA Langley Research Center is developing 
an Autonomous Operations Planner (AOP) that 
functions as an Airborne Separation Assurance 
System for autonomous flight operations. This 
development effort supports NASA ’s Distributed 
Air-Ground Traffic Management (DAG-TM) 
operational concept, designed to significantly 
increase capacity of the national airspace 
system, while maintaining safety. Autonomous 
aircraft pilots use the AOP to maintain traffic 
separation from other autonomous aircraft and 
managed aircraft flying under today ’s 
Instrument Flight Rules, while maintaining 
traffic flow management constraints assigned by 
Air Traffic Service Providers. 

AOP is designed to facilitate eventual 
implementation through careful modeling of its 
operational environment, interfaces with other 
aircraft systems and data links, and 
conformance with established flight deck 
conventions and human factors guidelines. 

AOP uses currently available or anticipated 
data exchanged over modeled Arinc 429 data 
buses and an Automatic Dependent Surveillance 
Broadcast 1090 MHz link. It provides pilots 
with conflict detection, prevention, and 
resolution functions and works with the Flight 
Management System to maintain assigned 
traffic flow management constraints. The AOP 
design has been enhanced over the course of 
several experiments conducted at NASA Langley 
and is being prepared for an upcoming Joint 
Air/Ground Simulation with NASA Ames 
Research Center. 


1 Introduction 

Despite recent economic and security concerns, 
demand for air travel is already meeting or 
exceeding previous levels and is projected to 
increase further [1-4], In response to these 
demands, NASA is investigating a new concept 
of operations for the National Airspace System, 
known as Distributed Air Ground Traffic 
Management (DAG-TM) [5]. DAG-TM has the 
goal of substantially improving airspace 
capacity, while maintaining or improving safety. 
It addresses these goals through a paradigm shift 
from a centralized, ground-based air traffic 
management system to a distributed network 
involving pilots. Air Traffic Service Providers 
(ATSPs), and aeronautical operational control 
centers. DAG-TM distributes responsibilities in 
a way that allows all participants to work within 
manageable workload levels, while reducing 
capacity limits and system bottlenecks. 

Under DAG-TM, separation assurance 
responsibilities are assigned to the most 
appropriate decision maker. Pilots flying 
appropriately equipped “autonomous” aircraft 
fly under Autonomous Flight Rules (AFR), 
where they are allowed to choose their own 
routes subject to maintaining separation from all 
other aircraft and conforming to traffic flow 
management constraints. ATSPs continue to 
provide separation services to “managed” 
aircraft unequipped for autonomous operations. 
Managed aircraft fly under today’s Instrument 
Flight Rules (IFR) and operate in the same 
airspace as autonomous aircraft. ATSPs also 
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issue waypoint constraints to all aircraft when 
needed to meet local traffic flow management 
needs. 

A robust Airborne Separation Assurance 
System (ASAS) is a key enabling technology 
for autonomous flight operations under DAG- 
TM. The Autonomous Operations Planner 
(AOP) developed at NASA Langley serves as a 
prototype ASAS that enables pilots to safely 
self-separate from other aircraft while meeting 
assigned traffic flow management constraints. 
It provides a conflict management tool suite 
consisting of Conflict Detection (CD), Conflict 
Prevention (CP), and Conflict Resolution (CR) 
capabilities. These tools are based on needs 
outlined by RTCA’s Airborne Conflict 
Management (ACM) Committee (RTCA SC 186 
WGl) [6]. The AOP integrates directly with a 
research prototype Flight Management System 
(FMS) to meet assigned waypoint time, speed, 
and altitude constraints. 

Although mature state DAG-TM is a far- 
term concept, the AOP has been designed to 
facilitate its eventual implementation onto the 
flight deck. Any new aviation technology must 
demonstrate to aircraft owners and operators 
that it can provide an immediate and significant 
benefit that substantially outweighs its 
implementation cost [4]. DAG-TM concept 
feasibility and benefit studies are addressing the 
former [7], whereas the AOP design has strived 
to seriously consider the latter. 

AOP design principles account for operator 
economic issues and global interoperability 
needs by emphasizing; 

• Effective operation using currently 
available and anticipated information. 

• Compatibility with existing aircraft 
systems and industry standards. 

• Pilot participation in a DAG-TM 
environment under acceptable workload 
levels. 


• Conformance to established flight deck 
conventions and human factors 
guidelines. 

These design goals are manifested by 
developing and evaluating AOP in a 
comprehensive environment consisting of 
internal and external systems interfaces and 
human-machine interactions. 

2 Modeling the AOP Operational 
Environment 

To meet the design goals described above, a 
simulated aircraft and airspace environment has 
been created that places a heavy emphasis on 
maintaining appropriate levels of compatibility 
with real-world avionics system architectures. 
This simulated environment is called the 
Airspace and Traffic Operations Simulation 
(ATOS) and resides within the NASA Langley 
Air Traffic Operations Laboratory (ATOL). 

2.1 ATOS 

The ATOS is a computer- workstation based 
airspace simulation that consists of many 
components, as shown in Ligure 1. The 
components include twelve individual simulated 
aircraft piloted by a single pilot, multiple 
pseudo-pilot workstations in which multiple 
simulated aircraft can be controlled by a single 
operator, a local air traffic generation tool to 
provide additional background traffic, and a link 
to the air traffic control services provided by an 
offsite facility (the NASA Ames Airspace 
Operations Laboratory). These components 
communicate with each other by passing data 
over TCP/IP using a High Level Architecture 
(HLA) communications bus. 
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Fig, 1, High-level Structure of the ATOS 


2,2 External ASTOR Communications 

The data passed over this bus are tightly 
eontrolled, in the sense that it is very elosely 
modeled after existing industry standards for the 
data that would be transmitted via radio signals. 
For example, aireraft state and trajectory intent 
data are based on the current version of the 
Automatic Dependent Surveillance Broadcast 
(ADS-B) Minimum Aviation System 
Performance Standards (MASPS) document [8]. 
Although the DO-242A specification has been 
extended in certain areas to support the new 
AOP functionality, great care was taken to 
maintain the underlying assumptions and 
limitations inherent in the industry standard. A 
similar approach has been taken for Flight 
Information Services Broadcast (FIS-B) data 
[9]. 

Traffic data are exchanged between air and 
ground stations over a modeled data link system 
that applies a probability of message reception 
vs. range between the transmitter and receiver. 
This range model considers message 


interference due to other data link messages and 
interrogations from secondary surveillance radar 
sites and aircraft Traffic Alert and Collision 
Avoidance Systems (TCAS). 

3 AOP Communications within ASTOR 

Each of the piloted aircraft workstations in the 
ATOS is called an Aircraft Simulation for 
Traffic Operations Research (ASTOR). Each 
instantiation of ASTOR represents a 
commercial transport aircraft, its flight deck 
systems, and the airborne components of a 
realistic future Communications, Navigation, 
and Surveillance (CNS) infrastructure. Current 
basic aircraft components include; aircraft and 
engine models; autopilot and autothrottle 
systems; Elight Management Computer (EMC) 
and Multi-function Control Display Unit 
(MCDU); Mode Control Panel (MCP) and 
Electronic Elight Instrumentation System 
(EEIS) control panel; EEIS displays such as the 
Primary Plight Display (PPD), Navigation 
Display (ND), and Engine Indication and Crew 
Alerting System display (EICAS); and sensor 
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systems such as an air data computer, satellite 
and inertial navigation units, and sensors and 
controllers associated with aircraft configuration 
(e.g., flaps, slats, and gear). The flight deck 


controls and displays of ASTOR are patterned 
after the Boeing B-777 airliner. An image of 
the ASTOR on-screen pilot interface is shown 
in Figure 2. 



Fig, 2, ASTOR Pilot Interface 


Advanced technology components of ASTOR 
include the ADS-B and FIS-B transponders, 
additions to the ND to support the display of the 
new ADS-B traffic information, a new traffic 
display control panel to manage this traffic 
information, and enhancements to certain FMC 
functions to support AOP conflict resolutions, 
such as improved required time-of-arrival 
(RTA) capabilities and the ability to fly non-idle 
descent paths. 

3.1 ARINC Data Bus Modeling 

The internal data flows between components 
within each ASTOR aircraft are accomplished 
using a simulated ARINC 429 data bus, which 
is described below. The specific sources of 
information provided to the new AOP are then 
presented within this context. 

3.1.1 ARINC 429 Data Bus Model 

To provide the desired combination of standards 
compliance and research flexibility, a new 
simulated ARINC 429 [10] avionics architecture 
has been designed and implemented to serve as 
the inter-process communications backbone of 


each ASTOR workstation. This simulated data 
bus models the equipment labels, channel 
definitions, and word labels of ARINC 429 
without duplicating the physical and electrical 
signal characteristics of real 429 bus hardware 
[11]. Each functional module of an ASTOR 
roughly corresponds to a current-generation 
avionics component, or to a new research 
capability that may eventually be incorporated 
into new or existing flight decks. To support 
the high data rates of many of these components 
without resorting to actual 429 bus hardware, a 
shared memory communications architecture is 
used. In order to promote the future rapid 
integration of AOP into flight test vehicles and 
to develop correct conclusions about the 
potential of AOP, as well as its associated 
system requirements, the contents of each 
channel on the bus remain as close as possible 
to the definitions described in the 700 series of 
ARINC characteristic documents (ref. ARINC 
702 A). As described in the next section, 
however, some extensions to the standards have 
been made to support the new research 
functionality. 
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3.1.2 Data Bus Extensions to support AOP 
New channels have been added to the simulated 
ARINC 429 data bus to carry the data produced 
by AOP. These new channels include AOP 
EFIS Output to carry data for the EFIS displays, 
AOP EMC Output to carry resolution flight 
plans to the EMC, and AOP MCDU Output to 
carry MCDU page data. 

In addition to these new AOP bus channels, 
AOP sometimes requires additional data not 
previously defined on several existing channels 
of the ARINC 429 data bus. For example, AOP 
needs waypoint crossing data (both flight plan 
requirements and trajectory estimates) for 
altitude, speed, and time to perform its traffic 
conflict detection. Therefore, the EMC 
Trajectory Intent Channel [12] has been 
extended by defining additional words to 


include this information. Although a detailed 
description of all of these additions and 
extensions to the simulated ARINC 429 data 
bus is beyond the scope of this paper, a high- 
level overview of AOP interfaces to other 
aircraft systems is presented below. 

3,2 AOP Interfaces 

To perform its separation assurance functions, 
AOP communicates with many other simulated 
onboard aircraft systems. As shown in Figure 3, 
these other systems include the EMC and 
MCDU, autopilot and autothrottle, existing 
EFIS control panel and MCP, air data computer, 
ADS-B and FIS-B transponders, EFIS displays, 
and a newly created traffic display control 
panel. 



Fig. 3, Overview of AOP System Interfaces 


All of these AOP communications with other 

aircraft systems use the simulated ARINC 429 3.3 other Aircraft Sub-systems 

data bus described above. 

Because the focus of this research effort is on 
DAG-TM, many aircraft systems not related to 
flight path management, flight guidance, or 
flight control have not been simulated. For 
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example, no models of an aircraft electrical 
system, hydraulic system, or pneumatic system 
have been included in the ASTOR workstation. 

However, for those systems that are 
required for investigations of new traffic 
management concepts, a considerable amount of 
effort has been placed into modeling them as 
accurately as possible. For example, the lateral 
and vertical flight guidance modes of the 
ASTOR autopilot, the FMC functions and 
MCDU pages, and the EFIS displays and 
control panels are implemented to be very 
closely matched to those found on the B-777. 

4 AOP Trajectory Processing 

Separation assurance applications needed to 
support autonomous flight operations rely on a 
comprehensive trajectory processing system 
within AOP. This system includes the assembly 
of ownship trajectory information for broadcast 
over ADS-B and the handling of incoming 
trajectories received by other aircraft. 

Aircraft trajectory information can be 
grouped into three different categories: state 
information (position and velocity), target state 
intent, and trajectory intent. Target state intent 
includes a singular set of horizontal and vertical 
guidance targets, such as commanded altitude, 
commanded heading or ground track, and 
commanded vertical speed. Trajectory intent 
includes multiple future target states and is 
typically in the form of an FMS or Area 
Navigation (RNAV) flight plan. These 
categories correspond to typical aircraft control 
states described below. 

Previous research suggests that some 
amount of intent information provides 
advantages for ACM applications [13-15]. 
Many other ASAS development efforts have 
trajectory processors that handle intent 
consisting of either some aircraft target states 
[16-17] or full FMS flight plans [13,18-19]. 

AOP employs a multi-faceted approach for 
handling trajectories that processes state 
information, target state, and trajectory level 
intent depending on the information available 
from either the ownship or nearby aircraft. The 


AOP trajectory processor has been designed to 
support a variety of different aircraft types and 
flying techniques that contribute to intent 
availability. 

4.1 Aircraft Control States 

The availability of aircraft intent depends in 
large part on its operating control state. Control 
states are affected by autoflight system 
capability and the choice of horizontal and 
vertical flight modes selected by the pilot. The 
three primary control states, referred to here as 
manual (no flight director), target state, and 
trajectory are shown in Figure 4. With each 
successive outer loop, more intent information 
is available for broadcast and separation 
assurance applications. 

When aircraft are flown manually without 
use of a flight director, only state (position and 
velocity) information is available. Under target 
state control, single commanded states are 
available in the horizontal and vertical planes 
(such as roll-out heading or level-off altitude, 
respectively.) In the outermost loop 

corresponding to trajectory control, the known 
aircraft trajectory consists of multiple trajectory 
change points and connecting flight segments. 
ADS-B target state and trajectory change 
messages provide a means for aircraft to 
exchange the corresponding level of intent with 
other aircraft and ground stations [8,20]. 

AOP must adhere to a complex set of 
trajectory processing requirements due to the 
multiple control state combinations that may 
exist between the ownship and nearby traffic 
aircraft. Most commercial aircraft have several 
flight modes corresponding to the target state 
and trajectory control states shown in Figure 4. 
Flight modes are normally selected through a 
flight control panel and include choices such as 
hold current heading, hold current altitude, and 
maintain track between FMS waypoints. For 
brevity, the flight control panel is hereafter 
referred to as the MCP. The pilot can 
concurrently choose horizontal and vertical 
flight modes that correspond to different control 
states, leading to different intent availability in 
the horizontal and vertical planes. 
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Fig, 4, Aircraft Control States 


Typical equipment sets on transport 
category aircraft (as shown in Figure 4) are 
capable of providing the associated information 
to AOP. Other flight hardware may also be able 
to generate this information. More sophisticated 
equipment is needed to access outer loop 
information and may be unavailable on older 
aircraft. An MCP is the primary interface 
between the pilot and autopilot when not 
operating in FMS automated modes. Pilots use 
the MCP for tactical operations by selecting 
interim target states such as altitude, heading, 
vertical speed, and airspeed. The FMS is 
generally programmed before flight through the 
keypad-based CDU. A pilot may program an 
entire route complete with multiple waypoints, 
speed, altitude, and time restrictions, and 
desired speeds along different flight segments. 
Changes may be made to the route description 
at any time during the flight. 

Pilots use the FMS to accomplish strategic 
goals such as tracking flight progress and flying 
an efficient route and altitude to the destination. 
They often leave the programmed flight plan, 
when trying to meet tactical goals such as 


avoiding thunderstorms or resolving near-term 
traffic conflicts. Under these situations, re- 
programming the FMS route is often time 
consuming and impractical. Instead, the pilot 
may dial a new heading or altitude on the MCP 
and engage a target state (tactical) flight mode. 

Complex paths may be created when an 
aircraft’s trajectory is generated in both MCP 
and FMS flight modes. Such a situation can 
occur when the horizontal and vertical modes 
correspond to different control states or when an 
autopilot target value interrupts an FMS planned 
trajectory. The latter case is most common 
when the MCP selected altitude lies between the 
aircraft’s current altitude and the programmed 
FMS altitude. In this case, the aircraft will level 
out at the MCP selected value. 

4.2 Command Trajectory 

A key feature of the AOP trajectory generator is 
its ability to create the command trajectory. 
The command trajectory is defined as the path 
the aircraft will fly if the pilot does not change 
the automation state or settings used to 
command aircraft guidance. It considers target 
states for active horizontal and vertical flight 
modes and any anticipated mode transitions. 
Changes to the command trajectory normally 
result from a pilot input. However, a non- 
programmed mode transition may also affect the 
command trajectory, such as reversion to speed 
priority on descent if the intended vertical path 
results in an over-speed condition. 

To generate the command trajectory, the 
AOP incorporates autofiight mode logic to 
determine the combination of active MCP, 
FMS, or aircraft state targets used to support 
guidance. These targets may include MCP 
selected heading or track, selected altitude, 
selected vertical speed, FMS waypoint 
predictions, or aircraft state targets. The latter 
may consist of current heading or current 
altitude when the aircraft is flying in a Heading 
Hold or Altitude Hold mode, respectively. The 
AOP must continually re-evaluate the aircraft 
state and system settings to ensure that the 
command trajectory is updated with the latest 
aircraft guidance and prediction information. 
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The command trajectory offers benefits for 
exchanging and processing intent in that it 
considers multiple flight modes and aircraft 
target states, rather than relying solely on FMS 
flight plans. It also incorporates onboard 
trajectory predictions and uses them instead of 
programmed autoflight system targets, when 
appropriate. Reliance on the latter can lead to 
erroneous trajectory predictions when a pilot 
action, environmental effect, or performance 
limitation prevents the aircraft from achieving 
the programmed target. 

For example, a previous pilot-in-the-loop 
experiment in the ATOL revealed an AOP 
deficiency in the determination of trajectory 
change point parameters [21]. To observe the 
interaction of two subject pilots engaged in a 
traffic conflict, both aircraft were intentionally 
assigned the same altitude and time constraints 
at a common waypoint. 

Several pilots conducted avoidance 
maneuvers that changed the aircraft’s actual 
crossing altitude and arrival time at the 
waypoint, although the original target values 
remained resident in the FMS. Example 
maneuvers included changing the FMS cruise 
altitude, restricting the FMS descent with the 
MCP selected altitude, and adding a path stretch 
that precluded meeting the required time of 
arrival. The AOP version used at the time 
continued to broadcast the FMS target 
parameters as trajectory change points, even 
though the own aircraft’s FMS was predicting it 
would not meet them. In this experiment, these 
problems led to inefficiency when one aircraft 
maneuvered after another had already resolved 
the conflict. An alternative situation could be 
envisioned where sending this hazardously 
misleading information could reduce safety if an 
aircraft failed to avoid a conflicting aircraft due 
to its broadcast of erroneous intent. 

The command trajectory provides a 
common definition for all users and helps to 
address some of these integrity issues. Various 
organizations have recommended its use for 
surveillance applications, including the FAA 
and Eurocontrol during a 2000 Technical 
Interchange Meeting on shared flight intent [22] 
and RTCA through its ADS-B MASPS [8]. 


Although no current aircraft system 
generates the command trajectory, there are 
reasons to believe it could be supported with 
modifications to current systems. Airbus is 
considering an EMS enhancement that would 
generate target altitude, a primary component of 
the command trajectory [23]. Honeywell flight 
management systems have access to many of 
the necessary MCP target states and aircraft 
predicted values over existing data buses [24]. 

In addition to preparing the command 
trajectory for broadcasting target state and 
trajectory change messages, the AOP must 
interpret these messages from other aircraft. 
Comparison of ownship and traffic trajectories 
forms the basis for the conflict detection, 
prevention, and resolution functions provided 
by AOP. 

5 AOP Traffic Management Functions and 
Flight Crew Interface 

Working with other onboard aircraft systems, 
the AOP enables pilots to perform the two 
primary tasks associated with autonomous flight 
management: self-separation from other traffic 
and area hazards and conformance with flow 
management constraints. In addition to 
accommodating existing standards for aircraft 
system and data link interfaces, the AOP design 
emphasizes commonality with established flight 
crew displays, controls, and procedures. 

As indicated in the previous section, AOP 
must incorporate design approaches to handle a 
variety of flight mode interactions, while 
keeping pilots “in the loop” and providing them 
with effective feedback on conflict situations. 
The discussion that follows describes the core 
AOP functions of CD, CP and CR in light of 
these requirements and indicates how AOP 
considers these additional tasks in the context of 
human factors design considerations. 

5.1 Conflict Detection (CD) 

The CD function provides long-range 
detection of conflicts between ownship 
trajectories and hazards, providing flight crews 
the time to develop and implement optimal 
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solutions. Any conflicts are ranked and alerted 
to the erew through visual and aural alerts that 
conform to the RTCA ACM Group’s guidelines 
on alert levels and implieations [6]. 

The four-dimensional command trajectory 
is compared with the incoming command 
trajectories from other traffic and the locations 
of hazardous weather areas and special use 
airspace to detect conflicts. It is also compared 
with time eonstraints assigned by the ATSP. As 
discussed above, some combination of state 
veetor, target state intent, and trajectory change 
intent are presumed to be available over ADS- 
B, as outlined in the ADS-B MASPS [8]. Intent 
availability is subject to operating aircraft 
control state, as discussed above. 

Confliet alerting is provided through flight 
deck displays and interfaces that are based 
closely on the Boeing 111 . Thorough AS AS 
researeh eonducted at the Berlin University of 
Teehnology has presented confliet information 
on Airbus style displays [18]. Three alert levels 
(as recommended by the RTCA ACM group) 
[6] are used to alert the crew to conflicts, with 
higher levels assigned to proximate and more 
hazardous situations. The Navigation Display 
in Figure 5 shows the ownship to be in eonflict 
with another aireraft at co-altitude. A solid 
amber bar along the current flight path indicates 
where the ownship is projeeted to lose and 
regain the minimum required separation. The 
AOP currently uses the FAA minimum 
separation in en route airspaee (5 NM or 1000 
ft). The conflict aircraft is shown in amber, 
consistent with the level of threat. When this 
level of conflict is first detected, the flight erew 
is also provided with a caution level EICAS 
message on the multifunction display and a 
corresponding aural alert. The use of existing 
displays and industry standards for alert 
symbology and annuneiation should enhance 
eomprehensibility and reduce the amount of 
necessary erew training. 

5.2 Conflict Prevention (CP) 

AOP’s CP function provides flight crews 
with guidance for conflict-free maneuvering in 
common guidance modes. This funetionality has 


been continuously refined and enhanced 
following suceessive human-in-the-loop 
evaluations of AOP prototypes at NASA 
Langley [15,21,25]. AOP’s CP funetion has 
both passive and aetive elements. 

The passive element provides the erew, 
upon pilot request, with “at-a-glanee” 
information on flight path ehanges that would 
eause near-term eonflicts. This CP information 
is presented to the crew by maneuver restriction 
(no-fly) bands on the ND and PFD as pioneered 
by the NLR [26]. As an enhancement, AOP’s 
no-fly bands are computed using available 
intent information from other aireraft. Figure 6 
presents an example of the symbology used to 
depict these no-fly bands on the ND. Assuming 
the pilot maintains the same vertieal eommand 
trajectory, a turn within a heading region of 150 
through 180 deg will cause a conflict with the 
other aircraft. 

The aetive element in AOP’s CP provides 
the crew with decision-support on proposed 
maneuvers, enabled by the crew eommunicating 
its intentions to AOP. Since AOP continuously 
monitors the MCP and CDU, it is aware of any 
FMS modified (MOD) routes and MCP 
heading/altitude seleetions that are yet to be 
executed. Therefore, when the crew ereates any 
sueh form of provisional intent, AOP creates 4- 
D trajeetories for that intent and performs CD 
on the provisional trajeetories. 

Pilots are alerted to any conflicts detected 
on these trajeetories through the ND, so that 
they ean evaluate the trajeetory and make an 
informed decision on implementing the intended 
route or target state changes. The alerts used for 
these provisional maneuvers are shown as 
dashed loss of separation bars along the 
provisional flight path. These bars indieate the 
points of first and last loss of separation if the 
maneuver were implemented, consistent with 
eonflict detection indications. 
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Fig, 5, Scenario Showing Conflict at Present 
Altitude and along FMS Profile Descent 

Figure 5 shows a provisional conflict along 
the current trajectory. The aircraft is flying 
along an FMS trajectory, prior to its Top of 
Descent (T/D). The flight crew has not yet 
dialed down the MCP altitude below the cruise 
altitude, a necessary pre-condition to enable the 
FMS descent at the T/D. An AOP provisional 
trajectory is created based on the crew 
performing this likely action. The dashed loss 
of separation region shows that a conflict will 
occur if the aircraft descends at the T/D. 
Provisional conflict detection supports the AFR 
requirement that pilots do not maneuver or 
change autoflight system settings in a way that 
causes near-term conflicts with other aircraft. 

In the scenario shown in Figure 5, the 
aircraft’s vertical command trajectory is to 
remain in level flight at the cruise altitude. This 
level flight trajectory is broadcast to other 
aircraft. The crew of the aircraft causing the 
provisional alert is currently unaware of this 
potential conflict situation. For this reason, 
AFR pilot training emphasizes the importance 
of checking for near-term conflicts prior to 
maneuvering. 


5.3 Conflict Resolution (CR) 

AOP’s CR function provides crews with 
resolutions in several common aircraft flight 
modes. They are presented to the crew through 
existing displays (PFD and ND) and crew 
interfaces such as the CDU. AOP supports two 
types of resolutions, referred to as strategic 
(trajectory-based) and tactical (target state- 
based). 

Strategic resolutions are computed as 
modifications to the FMS route and displayed as 
MOD routes on the ND. They provide crews 
with (a) a solution to the current conflict, (b) a 
return to the FMS route, (c) protection from 
creating future conflicts, and (d) conformance to 
active TFM constraints to the extent possible 
within ownship performance limitations. The 
crew is always in full control of the aircraft and 
its systems, and these resolution advisories are 
not created or implemented without crew input 
through the CDU. 

Tactical resolutions are presented to the 
crew as simple “go-to” headings, vertical speeds 
or altitudes that can be implemented by the 
flight crew either manually or through the MCP. 
They are annunciated as simple “bugs” on the 
ND and PFD. Time-to-conflict considerations 
determine the extent to which these resolutions 
protect the ownship from future conflicts. For 
near-term conflicts, implicit coordination 
techniques ensure that both aircraft are given 
compatible resolutions. To perform these 
coordinated resolutions, the AOP incorporates a 
modified voltage potential method refined by 
the NLR [26]. Again, the crew is in full control 
of the aircraft, and these resolutions can only be 
implemented by crew input through the MCP. 

AOP computes and provides resolutions 
that match the currently engaged flight modes. 
If the pilot’s horizontal and vertical flight modes 
correspond to the trajectory control state shown 
in Figure 6 (FMS guidance) AOP provides a 
strategic resolution if sufficient time to conflict 
remains. Otherwise, AOP gives a tactical 
resolution in the form of proposed target state 
changes. The green bug in Figure 5 is a tactical 
resolution suggesting a right turn. These 
features ensure that AOP is responsive to the 
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crew’s preferences in controlling the airplane 
[27], and that AOP’s resolutions are intuitive 
and comprehensible to the crew. 



Fig. 6, Conflict Scenario Showing Strategic 
Resolution and Maneuver Restriction Bands 

In Figure 6, the pilot has uploaded a 
strategic resolution into the FMS and it’s shown 
as a MOD route (dashed white line), using 
Boeing color and symbol conventions. This 
path resolves the conflict and returns the aircraft 
to its original flight plan. When the pilot 
executes this MOD route, the AOP will 
determine that a conflict no longer exists and 
will remove the loss of separation bar and no-fly 
bands. 

6 Conclusions 

AOP design has been driven by the need for 
compatibility with external systems, aircraft 
data sources, and flight deck conventions. It 
uses information available over modeled data 
buses and links, based on industry standards. 
The AOP incorporates a human-centered 
interface that leverages existing flight crew 
interface systems. Despite these features, 
additional work is needed to fully integrate the 


AOP into a separation assurance-dependent 
environment like DAG-TM. 

Most of the AOP development to date has 
focused on longer-term separation assurance 
rather than near-term collision avoidance. A 
previous study showed that pilots were able to 
use the tactical resolution cues to remain a safer 
distance from pop-up aircraft causing a near 
term conflict (RB ATM2003 paper). However, 
AOP design does not currently incorporate the 
Traffic Alert and Collision Avoidance System 
(TCAS). TCAS functions as a collision 
avoidance system and is standard equipment 
aboard commercial aircraft. An overall 
consensus exists that TCAS will provide 
necessary backup protection for separation 
assurance applications [4]. Considering this 
approach, the AOP design will need to address a 
number of important integration issues, 
including differences in resolution techniques 
between the tactical resolution system and 
TCAS resolution advisories and transition to a 
different source of aircraft state information. 
TCAS uses its own antennas to determine 
aircraft range and bearing, instead of ADS-B 
state vector messages. 

The AOP design described here will be 
evaluated in an upcoming Joint Simulation with 
NASA Ames Research Center. This experiment 
will address air/ground coordination issues for 
DAG-TM and will include both cruise and 
descent scenarios. AFR and IFR operations will 
be conducted in the same airspace, modeled 
after current Dallas Fort Worth sectors. Subject 
airline pilots at NASA Langley will use the 
AOP to maintain traffic separation and meet 
assigned altitude, speed, and time constraints at 
a terminal area meter fix. Subject controllers at 
NASA Ames will separate IFR aircraft from 
each other and assign flow management 
constraints to AFR aircraft. The experiment 
should provide a good opportunity to further 
improve upon the AOP design. 

Thorough consideration of aircraft systems 
and pilot performance issues have led to an 
AOP design that has contributed to promising 
results during initial DAG-TM feasibility 
studies [15,21,25]. Ongoing research and 
design enhancements will continue to address 
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detailed integration issues while providing 

effective decision support for pilots operating in 
complex DAG-TM environments. 
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